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REMARKS 

In the Office Action dated March 11, 2004, claims 1-5, 8, 13, 15-19, 21-26, and 
29-37 were rejected under 35 U.S.C, § 102(e) over Border (U.S. Publication No. 
2002/0071436 Al); claims 6, 7, 9-12, 14, 20, 27, and 28 were rejected under § 103 over 
Border in view of RFC 2516, entitled "A Method for Transmitting TTP over Ethernet 
(PPPoE)," dated February 1999 (hereinafter "RFC 2516"). 

Applicant respectfully submits that Border does not anticipate claim 1. Border 
describes a performance enhancing proxy (PEP) to perform 'TCP spoofing." Border, H 
[0014], Border describes TCP spoofing as involving an intermediate network device 
intercepting and altering, through the addition and/or deletion of TCP segments, the 
behavior of TCP connections to improve the performance of TCP connections. Border, If 
[0014]. In rejecting claim I as being anticipated by Border, the Office Action identified 
the "controller" recited in claim 1 as being the PEP disclosed in If [0014] and in Figure 
4A of Border. In particular, the Office Action referenced ihe local PEP endpoint 402. 
The Office Action asserted that the MSS (maximum segment size) value received in a 
TCP SYN segment (disclosed in [0014] of Border) constitutes the indication of size for 
a data portion of a first message recited in claim 1. Also, the Office Action stated that % 
[0275] of Border discloses the controller being adapted to modify the indication to 
indicate a different size for the data portion. 

Applicant respectfully disagrees with the assertion that Border teaches a controller 
to modify the indication (in a received first message) of a size of a data portion to 
indicate a different size for the data portion of the first message. Paragraph [0275] of 
Border describes tasks of a PEP performed in response to detecting an MSS mismatch, 
which occurs when a remote node reports a maximum supportable MSS value that is less 
than the MSS value sent by the PEP. In response to MSS mismatch, the PEP sends a 
message, referred to as a "datagram too big" message, back to the originating host. The 
"datagram too big" message includes an indication of the maximum supportable data size 
of the next hop in the network. Thus, the "datagram too big" message is an indication 
provided from the PEP to the originating host that the requested size for messages by the 
originating host is too large (the size cannot be handled by the remote node). See Border, 
U [0276]. This causes the originating host to break original TCP data segments into 
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smaller segments for retransmission. In sending the "datagram too big" message by the 
PEP to the host, the PEP does not perform the following combination of acts: receiving a 
message containing an indication of size of a data portion, and modifying the indication 
of the received message. 

In response to the "datagram too big" message, the originating host retransmits 
data segments in smaller segments: the retransmission of data segments in smaller 
segments by the host also does not constitute a controller receiving a first message that 
contains an indication of a size of a data portion, with the controller being able to modify 
the indication in the received first message to indicate a different size. 

Therefore, it is respectfully submitted that Border does not disclose the subject 
matter of claim t . 

Claim 16 was also rejected as being anticipated by Border. Claim 16 recites a 
method of indicating a message size that includes receiving (from a first network 
element) a first message to establish a connection between the first network element and 
a second network element, the first message containing an indication of a length of a data 
portion for messages to be communicated between the first and second network elements. 
The method further includes adjusting a value of the indication to indicate a different 
length, and sending a second message to the second network element to establish a 
connection between the first and second network elements, with the second message 
containing the adjusted value of the indication. 

As discussed above, Border does not disclose adjusting a value of an indication of 
a received first message to indicate a different length of a data portion for messages 
between first and second network elements. Moreover, Border does not disclose 
adjusting a value of the indication contained in a first message to establish a connection 
between first and second network elements. In addition, Border fails to disclose sending 
a second message to the second network element to establish a connection between the 
first and second network elements, where the second message contains the adjusted value 
of the indication. 

Independent claim 23 was also rejected as being anticipated by Border. Clam 23 
recites an article that includes at least one storage medium containing instructions that 
when executed cause a system to: receive (from a first network element) a first message 
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containing an indication of a size of a data portion for messages to be communicated 
between rust and second network elements; modify the indication to indicate a different 
size; and send a second message in response to the first message, the second message 
containing the modified indication. As discussed above, Border does not disclose 
modifying an indication in a received first message to indicate a different size of a data 
portion for messages communicated between first and second network elements. Nor 
does Border disclose sending a second message in response to the first message, where 
the second message contains the modified indication. 

Independent claim 31 is allowable for reasons similar to those for claim 23. 

Independent claim 32 recites a method of indicating a message si2e that comprises 
receiving a message containing a maximum segment size value, determining a maximum 
data size supportable by a link between the system and another node, and comparing the 
determined maximum data size with the maximum segment size value. The maximum 
segment size {of the received message) is modified based on the determination. In the 
Office Action, the modifying act of claim 32 was equated to the TCP Spoofing Kernel 
adjusting the size of data segments before sending them. See 3/1 1/2004 Office Action at 
6. Adjusting the size of data segments is not the same as modifying the maximum 
segment size value of a received message that contains the maximum segment size value. 
As clearly depicted in Figure 36 of Border (which was also referenced on page 6 of the 
Office Action in rejecting claim 32), the MSS value is contained in the CE message sent 
from the remote PEP to the local PEP (at 473). The data segment sent at 465 from the 
local PEP to the remote PEP has 1000 bytes of data. The 1000 bytes of data is divided 
into two segments each with 500 bytes of data, which are sent from the remote PEP to the 
remote host 406 (at 469, 471). However, breaking the 1000-byte data segment sent at 
465 into two 500-byte segments sent at 469, 471 does not constitute modifying the 
maximum segment size value contained in a received message 

Therefore, Border does not disclose the subject matter of claim 32. 

Independent claims 36 and 37 are similarly allowable over Border. 

Dependent claims are allowable for at least the same reasons as corresponding 
independent claims. Moreover, with respect to newly added claim 38, which depends 
from claim 1, Border does not disclose that the first message comprises a message to 
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establish a connection between first and second network elements, where the message to 
establish the connection contains the indication of the size of the data portion. Border 
also does not disclose a controller adapted to transmit a second message to establish the 
connection between the first and second network elements in response to the first 
message, with the second message containing the modified indication. 

With respect to newly added claim 40, which depends from claim 23, there is no 
indication in Border of receiving a first message (that contains the indication of size) to 
establish a session between first and second network elements, and sending a second 
message containing the modified indication to establish the session between the first and 
second network elements. 

Dependent, claims 6, 7, 9-12, 14, 20, 27, and 28 were rejected as being obvious 
over Border and RFC 25 1 6. In view of the defective application of Border to the 
respective base claims, it is respectfully submitted that the obviousness rejections are also 
defective, 

In view of the foregoing, allowance of all claims is respectfully requested. The 
Commissioner is authorized to charge any additional fees, including extension of time 
fees, and/or credit any overpayment to Deposit Account No* 20-1504 (NRB.0005US). 



Respectfully submitted, 



Date: June 8. 2004 




Dan C Hu, Reg. No. 40,025 
TROP, PRUNER & HU, P.C. 
8554 Katy Freeway, Suite 100 



Houston, TX 77024 
713/468-8880 [Ph] 
713/468-8883 [Fax] 



12 



PAGE 18/18 * RCVD AT 1217/2004 2:54:41 PM [Eastern Standard Time]* SVR:USPT0-EFXRF-1/7 * DNIS:8729306 • CSID:7134688883 • DURATION (mm-ss):04-54 



